CREATE USER <name> and ALTER USER <name> SET ... parse on their own, but CREATE USER user1; SELECT 1 (and the two ALTER USER ... SET forms) fail with Expected: end of statement, found: SELECT. The trailing option list is read by parse_key_value_options, whose loop drives on next_token() and breaks on a ; that it has already consumed. With the terminator gone, the top-level statement loop sees the next statement's first token directly and errors out. The bug is dialect independent and affects every unparenthesized caller of the helper: CREATE USER and both ALTER USER ... SET branches. Statements that never reach the helper (CREATE ROLE, DROP USER, ALTER USER ... RENAME) are unaffected, as are the parenthesized callers, which end on ).

This puts the semicolon back with prev_token() before breaking, so the caller and the top-level loop still see the separator, mirroring how the existing end-keyword arm already does it. The EOF arm needs no rewind. Fixing the single helper repairs all three statements at once. A regression test parses each of the three forms followed by SELECT 1 and asserts two statements result.